I see that not only the job that I'm migrating to self-hosted runners, but also Clippy and Test in release mode on MacOS have started failing now with the same error:

error[E0282]: type annotations needed
   --> src/seal.rs:339:5
    |
339 |     filecoin_proofs_v1::clear_cache(cache_path)
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type of the type parameter `Tree` declared on the function `clear_cache`
    |
help: consider specifying the generic argument
    |
339 |     filecoin_proofs_v1::clear_cache::<Tree>(cache_path)
    |                                    ++++++++

error[E0282]: type annotations needed
   --> src/seal.rs:426:5
    |
426 |     filecoin_proofs_v1::clear_synthetic_proofs(cache_path)
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type of the type parameter `Tree` declared on the function `clear_synthetic_proofs`
    |
help: consider specifying the generic argument
    |
426 |     filecoin_proofs_v1::clear_synthetic_proofs::<Tree>(cache_path)
    |                                               ++++++++

Last month they were still passing on the default branch: https://github.com/filecoin-project/rust-filecoin-proofs-api/actions/runs/15213629917

@vmx Do you have an idea why that might be?

cc @BigLep

Things should work, but the current master patches the rust-fil-proofs crates to point to the master branch:

As there was a release of rust-fil-proofs, this repo should be updated to use the released version. So I suggest that the current maintainers update to those versions and the we'll see if things still fail.

I added a release commit here - c5246a9 - and the workflow now passes.

Now, the question is, what the release process is that we should follow? I see that the previous tags were created manually - https://github.com/filecoin-project/rust-filecoin-proofs-api/tags

Thanks for the updates @galargh.

@galargh : Would it maybe make sense to break this into two PRs (one for the release, and one for the CI adjustment)?

@vmx : are there any steps we should follow for making releases (e.g., any cargo release commands like with rust-fil-proofs)?

The release commit in here had me confused, but I think we're just trying to do two separate things at once? I don't think I mind as long as it's not squash merged, but it would have been clearer for reviewing if they were separate PRs.

My only question is about the nvidia drivers--are they already installed on the standard GitHub machines but not on the current AMI that we have access to?

I would do the release separately. It's done similarly as for rust-fil-proofs. It's even simpler. It's a matter of cargo release major. It would do the version bump in the Cargo.toml, push that tags etc.

The release commit in here had me confused, but I think we're just trying to do two separate things at once? I don't think I mind as long as it's not squash merged, but it would have been clearer for reviewing if they were separate PRs.

Yes, that was the plan all along. I just wanted to see whether the release fixes the build on self-hosted runners. Here's the separate PR that I just created: #109

My only question is about the nvidia drivers--are they already installed on the standard GitHub machines but not on the current AMI that we have access to?

The hosted runners do not have GPUs. On self-hosted ones, we do have dedicated GPUs - that's what we install the drivers for.

@galargh : It looks like the content of #109 is still in this PR. Once it's removed here, I tink we can approve and get this merged.

@galargh : It looks like the content of #109 is still in this PR. Once it's removed here, I tink we can approve and get this merged.

I moved this one back to draft for now as it's effectively blocked until we get the release out.